Day21. 佛系生存法則：能實作 MCP 是本事，不刻意炫技才是真高招。

17th鐵人賽

楊舒安

2025-10-05 00:27:09

137 瀏覽

分享至

前情提要：
Day20. 只是為了流行才用 MCP（模組上下文協議）協作嗎？一起來看「春秋戰國時代」的上班族日常吧～

第十回：帝國資安警報

某日，AI始皇 無預警的發出警告：「資安警報：發現可疑連線，請立即登出並關閉可疑帳號。」資安部門忙得天翻地覆，把所有USB、私接VPN都一一拔掉，就像大樓管理員把每個門禁都重新掃描一遍。

(圖片來源：由 Perplexity 協助圖片生成)

不只資料外洩，舊系統留下的漏洞也被 AI始皇逐一清理，像是所有老台式機都要強制安裝最新資安驅動，誰敢不理，半小時後帳號就自動鎖死。

第十一回：資安之下的日常焦慮

阿趙這幾天精神緊繃，因為 AI始皇時不時就在跑資安審查模組，所有私訊、社群消息、外包合約全部自動比對，甚至連播個音樂都要過授權認證。
他嘴裡嘀咕著：「人生第一次連聽歌都怕被貼上『資安有疑慮』的標籤，以前只要擔心會被貼上『不愛台灣』的標籤，現在則是標籤都還沒貼上，就直接列入違規行為。」

打卡下班時，手機還會收到通知「資安健康報告」：

未授權App：情節輕微，記警告一次
雲端資料同步：已備份
指紋掃描異常：自動隔離

走到公司門口準備離開時，AI始皇還會送上一句：「自由的標準，早已備份在MCP協議裡，在資安的世界裡，工作時是連休息都要符合規定的呦～明天見！」

本日重點

解讀 MCP 實作在現代專案中的價值與限制
為什麼業界強調「能實作不炫技」的技術心態
佛系工程師觀點下的 MCP 團隊協作經驗
MCP 技術實作的常見落地困難與最佳實踐
如何在協作中均衡創新、實用與溝通效率

一、看到這裡，先想想 MCP 的必要性？

想像一下，買了一台微星的AI微型PC：EdgeXpert MS-C931 回家，結果每天只會用到「小算盤」的功能，那這台 PC 就是大材小用；MCP 大概也是這樣，如果專案規模不大，導入 MCP 就像是開著私人飛機去巷子口買早餐一樣，技術上沒問題，但總覺得哪裡怪怪的。

有時候，最好的解決方案就是最簡單的那個。如果現有的工作流程已經夠用，團隊合作順暢，客戶滿意度也不錯，只是為了「跟上時代」而導入 MCP，每天光是維護這套系統的設定檔、檢查模組相容性、處理版本更新，可能就比實際工作還累人。

這樣不是不行，只是有點不切實際。

二、認識 MCP

1. MCP 是什麼？

MCP（Model Context Protocol，模型上下文協議）是近年來 AI Agent 與大型語言模型應用領域的一項重要技術標準。它的核心理念，就是讓 AI 不再只是孤立的文本生成工具，而是能透明地管理「上下文」、精確串接「多模組」、控管「安全」與「流程擴充」的智慧協同橋樑。

2. 以 AI 營養顧問為例

提出一個飲食問題，MCP會先整合過往健康紀錄、查詢相關知識庫、協調外部API，最後才決定如何讓語言模型生成最合適的回覆。在MCP的架構之下，系統會將每個步驟都模組化拆分，像是：

分層/規劃項目	說明內容	實作要點/特色
Controller	主控流程派送、協調各服務模組與使用者請求	負責調度與權限判斷
Service	API/功能接口模組化，獨立部署/測試	易維護與擴充
Context Retrieval	動態檢索現有資料（如RAG語意/FAQ），聚合相關context	可串知識庫、歷史紀錄
Protocol Handler	定義上下文組裝規則、資料流監控、權限控管	資安檢查，防資料外流
Model (LLM/AI)	擔任最後生成者，執行語言理解與決策	可替換各種模型
資料流監控	查詢均經 Protocol Handler/RAG聚合，最後回應LLM	Trace/日誌完整
擴充/資料類型管理	dataclass/pydantic等結構化管理複雜prompt/context	明確類型檢查、易debug
安全性規劃	核心納入資安檢查與權限控管，API/Agent接入前需審查	防攻擊與未授權存取
例外/回滾機制	漏資料、模型/API異動時可復原、回滾	穩定性強，易擴充升級

示意圖

Controller
  ├── Service 
  ├── Context Retrieval
  ├── Protocol Handler
  └── Model (LLM/AI)
          ├── 資料流監控（RAG）
          ├── dataclass/pydantic 資料型別管理
          ├── 資安權限控管
          └── 回滾/例外復原

示意圖補充說明：

Controller：統一管理用戶請求與後端服務派送
Service（Interface）：每個API與功能的細節包裝
Context Retrieval（上下文檢索）：動態取得現有資料
Protocol（協議核心）：協調如何組裝、輸出和安全流通
Model（AI）：負責輸出解答與互動結果

三、專案中的 MCP

1. 類似 MCP 的設計方式：

目前專案沒有全面採用 MCP（部分採用，例如：FAQ 功能有加入 RAG，請參閱：Day27，Day28），以及對於專案流程的設計，筆者還是有加入 MCP 的精神，例如：「上下文管理」、「模組介面清楚分離」、「Prompt 流程規劃」...等等。

2. 未來會如何設計和規劃本專案的 MCP：

分層設計：Controller（主控）- Service（服務接口）- Context Retrieval（上下文檢索）- Protocol（協議核心）- Model（LLM/AI）。
資料流監控：每一個查詢都經過 Context Protocol Handler，由 RAG 層檢索/聚合，最後整合給 LLM。（例如：專案的 FAQ 功能有加入 RAG，請參閱：Day27，Day28）
擴充性考慮：使用資料類別（例如 dataclass, pydantic）管理複雜的 prompt/context。
安全性規劃：資安檢查與權限控管必須納入 MCP 系統核心，否則將來接入外部 Agent 或 API 反而更容易被攻擊。
例外處理：考慮到遺漏資料、模型更新、API 變更，都需要 MCP 有「復原機制」或回滾設計。